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Introduction 

Military information processing systems 
often involve inordinate and unnecessary expend- 
itures on the part of both industry and the mili- 
tary. On the one hand, industry frequently 
invests heavily in preparing what they consider to 
be realistic and competitive responses to RE- 
QUEST FOR PROPOSALS (RFPs) only to find that 
much of their time, effort, and funds have been 
wasted. Poorly specified performance and op- 
erational requirements in the RFP (resulting 
from virtually no requirements analysis), and the 
uncertain selection methods, frequently make the 
subsequent awards seem arbitrarily determined. 
On the other hand, following the contract award 
the m.ilitary often expends much greater funds 
than initially programmed because of contract 
modifications resulting froin greatly changed 
requirements — differences between the require- 
ments as stated in the initial specifications and 
those that the system is ultimately expected to 
meet. In extreme cases the fabrication of the 
system may be nearly completed before the actusil 
system requirements are determined. 

Although many of the effects and a major 
part of the problem results from the near failure 
of industry and the scientific community to pro- 
vide acceptable characterizing functions and 
performance measures for large or medium 
scale information processing systems, a major 
part of the problem stems from the failure of the 
military to perform or attempt a requirement 
analysis with available techniques, even though 
imperfect. Our immediate concern and the main 
orientation of our discussion is toward the latter 
aspects of this joint problem; accordingly, we 
place emphasis on the fact that in attempting to 
describe what is actually desired from (or goes 
into) the information processing system, the 
document called SPECIFICATIONS rarely, if 
ever, contains a sufficient enumeration of the 
particulars to define the requirements for the 
system. 

The origins of many large scale military 
information processing systems often can be 



traced back, at least in part, to earlier systems 
initially mechanized by a variety of special pur- 
pose equipments, or "black boxes, " which were 
generally designed to execute explicit functions 
with certain performance standards in a given 
operational environment. Because many systems 
of an earlier time period essentially were as- 
sembled without current techniques such as found 
in systems engineering, operations analysis, and 
cost— effectiveness studies, any interconnection of 
black boxes and people that could (usually) eco— 
nomicsdly increase the capability of the military 
to perform its mission was generally acceptable. 
However, more recent analysis and synthesis 
techniques associated with the above-mentioned 
fields and others, notably that of computer design 
and programming, have brought about some (and 
offer even more) significant increases in the 
capability (and com.plexity) of military information 
processing systems. There has been at least 
one inajor consequence universally accepted in 
principle although not always practiced. This is 
the integrated systems design approach as op- 
posed to a never ending series of ad hoc or quick 
fixes to modernize outmoded systems. 

The improvements to be gained by the sys- 
tems approach are, however, not without some 
special and difficult problems. A cardinal 
problem — the specification of the military infor- 
mation processing system — provides the central 
theme of this discussion. Even a general dis- 
cussion of this important problem involves great 
difficulties since a complete characterization 
would suggest that there is some generally 
accepted and unambiguous usage of terms. Un- 
fortunately, such is not the case. The authors 
have found, both in discussions with their col- 
leagues and in examining some system specifi- 
cations, that there are frequent occasions when 
operational requirements are almost inextricably 
intertwined with either performance or functional 
requirements, or both. Consequently, we 
attempt to clarify some commonly used and mis- 
used terminology to aid in providing an adequate 
characterization of the problem of specifying the 
system. 



Any views expressed in this Paper are those of the authors, and should not be interpreted as 
reflecting the views or opinions of The RAND Corporation or the official opinion or policy of any of 
its governmental or private research sponsors. Papers are reproduced by The RAND Corporation 
as a courtesy to members of its staff. 

This Paper was prepared for presentation at the 1964 National Winter Convention on Military 
Electronics, February 5—7, 1964. 



-2- 



The problem of selecting the system is 
clearly bound up with the problem of specifying 
the system. Cost-effectiveness analysis can 
provide a general methodology for optimal selec- 
tion of some systems under certain constraints. 
However, such analysis is heavily dependent upon 
the knowledge and availability of performance 
measures and costs that can be quantified. The 
major obstacles to accruing this knowledge are 
noted and some methods of circumventing them 
(as an expedient only) will be discussed. 

The Nature of the Specification Problem 

The spectrum of military information pro- 
cessing systems very nearly covers the entire 
range of military systems. It includes command 
and control systems (both strategic and tactical), 
logistics systems, reconnaissance systems, 
intelligence systems, some types of weapon 
systems, and certain other types of systems. 
It is reasonable to hope that as the body of know- 
ledge of the information sciences grows, some 
growth can be achieved in military science. In 
this regard it should be noted from past experience 
in other fields that the introduction of data pro- 
cessing and digital computer technology into a 
new field, causes a concentration of personnel, 
experience, and talent in the related information 
sciences which usually brings a greater formalism 
to that field. This results in a better under- 
standing of many aspects of the field and usually 
helps produce significant improvements. 

However, it may be unrealistic to expect 
relative parity in growth between the military and 
information sciences. Growth of knowledge in 
most scientific areas is largely the result of 
experiments and operational experience. The 
multifarious activities of industry, science, and 
business can be considered as complementary 
areas increasing the base of the information 
sciences. Military science has, unfortunately, 
the combat environment as its principal laboratory 
in which further factual knowledge is gathered, 
although large— scale computer simulations show 
good promise of providing a similar kind of know- 
ledge in a much healthier environment. However, 
the relative increase of knowledge of one branch 
of science over another should not impose greater 
problems than those with which we are currently 
faced, if we can get over the hurdle of estab- 
lishing a common basis for specifying the require- 
ments for a military information processing 
system. We will not attempt to conjecture on the 
magnitude of the problem to be faced in the fu- 
ture if we postpone the effort to establish this 
basis for specifying systems that will be even 
more sophisticated than those that are currently 
required. 



The nature of the difficulty can best be de- 
scribed as a peculiar combination of two extremes 
of problem definition. On the one hand, there is 
often an explicit description of the functions to be 
executed by a number of black boxes with certain 
performance standards. On the other hand, there 
is usually a vague, if any, description of the oper- 
ational concept and requirements for the overall 
system. The best that can be expected from such 
a specification is optimized sub— system design 
because of the fairly well defined black box 
elements of the system. However, sub— optimiza- 
tion might not even result in satisfactory overall 
system performance. In spite of this possible 
consequence, proposals are still requested, sub- 
mitted, and accepted on the basis of partial systems 
configurations of various black boxes even though 
both the military user and the industrial contractor 
are often painfxxlly aware of the existing defi- 
ciencies of our current methods of specification. 

Although there may be several other approaches 
to deriving system specifications that are of suf- 
ficient importance to be noted, we will briefly 
consider only two alternative approaches here, in 
addition to the approach we advocate, since a 
more comprehensive discussion of possibilities 
is beyond the scope or the intent of this paper. 
Furthermore, these two will provide sufficient 
contrast for the approach that we advocate. The 
first approach is the determination of system 
specifications as a result of a study contract 
awarded explicitly for that purpose. This, has 
some merit since it generally involves a great 
deal of interaction between the military and indus- 
try in the performance of the study and its essen- 
tial objective is the elimination of non— coherent 
specifications— the central theme of our discussion. 
Such an approach might be the most efficient 
current method to help achieve a realistic imple- 
mentation goal, particularly if the study results 
should reveal blind development alleys which 
might have been undetected otherwise. 

The second approach essentially amounts to 
determining the requirements of the system as the 
initial phase of an implementation contract. 
Although in mainy instances this phase of the con- 
tract is not so obviously stated, the necessity of 
such a phase is sometimes evident by virtue of the 
technically vague and often contextual descriptions 
of the tasks the system is required to perform to 
achieve its objectives. These instances are not 
actually characterized by imperfect specifications 
since they are not spelled out. For this type of 
contract the military designates a particular 
organization as a preferred prime systems con- 
tractor because of directly related experience, 
demonstrated capability, and past performance 
not readily available elsewhere. 
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It seems unlikely that procurement pro- 
cesses win be changed to the extent that all, or 
even many, of the future military information 
processing systems will be specified from require- 
ments derived directly as a result of study con- 
tracts awarded for that purpose. Furthermore, 
it seems to us that such a course of action would 
be self— defeating in the long run, even though 
meritorious in some instances, since it does not 
lend itself to the most effective concentration of 
manpower and capabilities. A similar argument 
against the second approach (including a specifi- 
cation phase in an overall contract) can also be 
made. 

The approach we advocate is for the m.ilitary 
to specify their requirements. The military 
should always be in the best position to examine 
and continually analyze the requirements imposed 
on the system by the operational uses for which 
it is intended and the organizational and envi- 
ronmental structure within which it will be 
operated. The corollary is for industry to con- 
centrate its manpower and capabilities in the area 
in which it is best qualified — systems, hardware, 
and software design. This is not to say that the 
military should not or does not have competent 
system.s designers nor that industry should not 
or does not have competent military operations 
analysts. Such com^plementary capabilities are 
useful to help promote greater cooperation and 
understanding of each other's problems. How- 
ever, it must be emphasized that as the user, the 
military is in the best position to know, or to be 
able to ascertain, the detailed requirements that 
the system must meet; likewise industry, as the 
designer and manufacturer, is in the best position 
to determine how to convert these requirements 
into hardware and software. 

Operational, Performance, and Functional 
Requirements 

The requirements that a system must meet 
can be divided into three major categories that 
we will call operational requirements, performance 
requirements, and functional requirements . If 
we accept the definition that performance em- 
bodies the notion that one or more functions are 
carried out to completion, without undue regard 
to quality or relative standards for individual 
functions, we can reduce the number of cate- 
gories of requirements that a system must meet 
and only consider the performance requirements 
and operational requirements. 

The performance requirements are those 
that determine what a system must be capable of 
doing — i.e., what characteristic tasks it should 
perform. For an information processing system, 
these can be stated broadly in terms of the 



information available to the system, the outputs 
that the system must generate from the available 
inputs, and the response time required and/ or 
delay times permitted, but they shovild not be 
concerned with the internal machine functions to 
be executed; i.e. , the information transfer 
functions . The operational requirements are 
those that determine the conditions, restrictions, 
and limitations which are imposed on the system 
or under which it must operate while meeting its 
performance requirements. They determine the 
operating methods and conditions such as mobility, 
ruggedness, environment (temperature, humidity, 
dust), shock, vibration, weight, size, electro- 
magnetic interference, radiation resistance, 
vulnerability, survivability, maintainability, 
logistics support, and personnel training and 
qualifications. Cost, of course, is a subject now 
recognized as essentially related to system effec- 
tiveness or capability. 

Performance and operational requirements 
can be considered separately although the oper- 
ational requirements will usually have some effect 
on the ability of a particular hardware mechani- 
zation of a system to meet its performance 
requirements. Basically, a first cut at the (paper) 
system design should be based on the performance 
requirements keeping in mind insofar as possible 
the operational requirements. After this phase of 
the system design has been completed, the oper- 
ational requirements should then be superimposed 
on the hypothetical system making compromises 
and modifying the design where necessary. In 
some cases, several iterations of a preliminary 
design relating performance requirements and 
operational requirements may be necessary. 

Son-.e further aspects of per for nuance require— 
rr.erits will be discussed next, keeping in n-ind that 
the resulting preliminary system design will prob- 
ably be modified by operational requirements. 

Performance Requirements 

The performance requirements of an 
information processing system can be 
and should be completely defined by list- 
ing the following factors: 

o All of the available inputs . 

o All of the required outputs . 

o The response times and/ or 
delay times permissible for 
the execution of functions in 
each case. 
In listing the inputs and outputs it is not suf- 
ficient to identify them by function name only . 
Each input and output should be specified in as 
much detail as possible depending upon the know- 
ledge of the system interface requirements. 
Whenever possible this information should be in 
terms of the number of characters, digits, orbits 
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involved, the volume, the rate, the priority or 
significance, the accuracy and precision, and the 
frequency of occurrence of each item. Addi- 
tionally a detailed breakdown of items into sub- 
items down to the smallest unit of input/ output 
information for the system should be stated. 
This is the kind of information that should be 
determined by the military from a detailed re- 
quirements analysis and then specified in the 
request for proposal as the requirements for the 
system. Note that none of the details of the 
internal information processing is included. It 
should be the bidders', and ultimately the con- 
tractor's, choice to determine the best way to 
generate the required outputs from the available 
inputs. In an information processing system, 
this is the core of the systems design problem 
and is one that frequently can be handled in a 
number of different ways. 

As noted above, the system design problem 
is largely that of determining how to generate the 
required outputs In the given time frame from 
whatever input information is available . It is 
therefore necessary to relate the items of output 
information to the items of input information 
from which they are derived or, in engineering 
parlance, derive the transfer functions. A sub- 
sidiary, but nonetheless major, step of the design 
problem is to determine the number and types of 
equipm.ent or black boxes required, how they are 
organized within the system, and what sub— set of 
functions each must perform. This information 
will help determine the input/ output equipments 
required, the file storage capabilities required, 
the internal storage requirements, the functions 
that must be perform.ed by the computers or data 
processors, the internal speeds required, the 
communications between equipments, the multi- 
plexing and time sharing requirements, and most 
of the other functions that will help to identify 
each unit of equipment In the system and conse- 
quently specify its detailed characteristics and 
capabilities. 

There are usually many alternative system 
configurations that might meet the performance 
requirements. The selection of the various com- 
binations of these tasks and equipments should be 
left to the bidders with the military reviewers 
and evaluators determining which configurations 
satisfy the performance standards required. The 
final determination of system configuration would 
be the responsibility of the system contractor with 
the approval of the military user. Such procedures 
will encourage industry to exercise its initiative 
and capabilities without feeling that it is required 
to conform to some initially specified and perhaps 
arbitrary system organization. The military will 
reap the benefit of alternative system concepts 
from which they can select the one that best meets 



their requirements consistent with either a budget 
or capability criterion. 

Operational Requirements 

Once a first cut has been made at the system 
organization and configuration to meet the per- 
formance requirements, the operational require- 
ments can be imposed on a conceptual system 
design to effect the modifications and compromises 
where necessary. 

At this step some trade-offs between perform- 
ance and operational capability might be required. 
For exan:iple, mobility may require a different 
modular breakdown of equipments or a different 
type of mass menaory; environmental conditions 
may require a different type of internal memory 
or input/ output unit; electro— magnetic inter- 
ference and vulnerability may impose limitations 
on the transfer of data between physically sepa- 
rated units; maintainability and personnel train- 
ing may require automatic trouble location tech- 
niques and a greater standardization of basic 
modules; and survivability may require dispersion 
of the system into physically separated modules 
with a capability for degraded performance fol- 
lowing the loss of any unit. After the military has 
specified the operational requirements imposed by 
the uses to which the system is to be put and the 
conditions under which it must operate, industry 
should determine how to meet these operational 
requirements while maintaining the ability to 
meet the performance requirements. 

In some cases it will be found at this stage of 
design that the state— of-the— art is such that both 
the performance and operational requirenaents 
cannot be miet without making some sacrifices in 
one or the other, although (hopefully) some trade- 
off might be made between them. The question of 
whether or not to attempt advanced development 
(improve the state-of-the— art) should be clearly 
asked and unequivocally answered. If not, at this 
point the systems contractor should provide the 
military with a sensible set of performance 
measures, and perhaps a like set of operational 
effectiveness measures , so that the military 
customer could exercise his judgment in the 
selection of those trade-offs he deems desirable 
by the system design and configuration. In 
principle, the existence of a set of alternative 
system choices with appropriate and commen- 
surable performance and operational effectiveness 
measures can provide both the military auid indus- 
try with a powerful tool for system selection known 
as cost— effectiveness, which will be considered 
further in the following section. 

The systems contractor should recommend 
trade-offs between performance or operational 
specifications that are primarily to permit an 
efficient mechanization of the system, and the 
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military should be able to determine whether 
these trade-offs are acceptable or specify alter- 
nate ones where they are not acceptable. To a 
large extent, the successful design of a system 
(i.e. , one which is capable of accomplishing the 
main purposes for which it was intended) is 
frequently a matter of making the proper— com- 
promises between the performance and oper- 
ational requirements as embodied in the system 
design. Both the military and the systems con- 
tractor have a great stake in this and each can 
best contribute in his own area. 

Cost-Effectiveness Analysis: A Method for System 
Selection 

It was noted above that the method by which 
a system naight be fairly and objectively selected 
would be a cost— effectiveness analysis. This 
kind of analysis assumes that knowledge of two 
major factors associated with the system are 
available or can be determined. These factors 
are: 

o The system performance and oper- 
ational effectiveness measures, 
o The total system costs, which of 
necessity includes the operational 
and maintenance costs. 
The basis of selection could be established by 
this method using one of two approaches de- 
pending upon the circumstances . 

The first approach assumes a fixed budget, 
hence the total system costs are constrained. 
The system is then selected by choosing the one 
which maximizes the system performance (or 
effectiveness) without exceeding the cost con- 
straint. The second approach assumes some 
fixed level of operational effectiveness that must 
be achieved. For this method, the selection 
scheme is to choose the system that achieves the 
desired effectiveness with a minimum of system 
costs. Under certain circumstances, these 
criteria are essentially equivalent. This selec- 
tion of one or the other approach is generally 
dependent upon the ease of analysis, the available 
information, and the intended use for the analytical 
results. 

It is not our intention to present an expo- 
sition of the merits and methodology of cost- 
effectiveness analysis; this topic is treated 
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adznirably elsewhere. However, It is our inten- 
tion to point out that this technique, which can be 
of immense value to both the military and industry, 
is not yet of particular use for the selection of 
military information processing systems, or, for 
that matter, for many other kinds of information 
processing systems. A major obstacle is the 
current lack of good methods for characterizing 
the functions and performance of information 
processing systems. 

It is of extreme importance to emphasize the 
distinction between characterizing functions and 
establishing performance measures for infor- 
mation processing systems on the one hand, and 
of analyzing and specifying the requirements for 
the objectives and mission of the system on the 
other hand. It follows logically, from the ob- 
served results of some sciences as applied in 
other fields as well as from what we have said 
previously, that the former tasks (characterizing 
functions and establishing performance measures) 
are mainly the responsibility of industry and the 
scientific community and the latter tasks (analysis 
and specification of the requirements for the 
objectives and mission) are the responsibility of 
the military. 

The lack of good performance measures and 
characterizing functions for data processing 
systems is not only an obstacle to the economic 
selection of information processing systems, but 
it is a significant impediment to an adequate 
dialogue between designers and users. The pro- 
longed existence of semantic ambiguity in this 
field might offer some a slight advantage in 
brochuremanship, but it is a definite disservice 
to the joint endeavors of industry and the military 
as a whole. 

Even though there is little in the way of an 
adequate language, and perforniance measures 
and characterizing functions to help establish 
criteria for system^ selection are virtually non- 
existent, one should not conclude that the situa- 
tion is completely hopeless. There are some 
reasonable steps that can be taken to insure that 
there is at least an awareness of some of the 
factors that might be taken into account in selec- 
ting a system. For example, if there is some 
critical time scale for design and fabrication of 
the system the military should make these facts 
known . The need for the system to evolve in accord- 
ance with some current or future specifications 
might be very important and could have significant 
effect on the design and consequently the costs . The 
number of total systems that are involved is an ob- 
vious factor of great importance, but the commonality 
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of the operational requirements for all units and 
the number and kind of specific differences for 
specific numbers of units is also of importance. 
These and other factors can have a significant 
impact on both the costs and efficiency of the 
system. Because of these considerations and 
others previously noted it is of the utmost im- 
portance that the military provide industry with 
their most accurate appraisals of the operation 
and performance requirements for the system. 

Concluding Remarks 

The military and industry jointly and 
separately have important jobs to perform in the 
specification and selection of m.ilitary infor- 
mation processing systems. Each should attempt 
to accomplish those tasks for which it is best 
suited. The military, as the user and customer, 
should concentrate on the requirements analysis 
in order to determine both the detailed perform- 
ance and operational requirements that the pro- 
posed system must meet. Specifications, 
partially in terms of equipm.ent and their charac- 
teristics, and partially in terms of the oper- 
ational environment, are an inadequate sub- 
stitute for a requirements analysis . Conversely, 
industry should concentrate on designing a system 
to generate the required outputs from the available 
inputs within the given time constraints while 
meeting the operational requirements . 

A proper and adequate requirements 
analysis performed by the military might also 
help eliminate industry's sometimes inadvertent 
attempts to reorganize the military or attempt to 
redirect their assigned mission in order to bring 
into consonance their view of the requirements 
and objectives of the systems design. 



